package com.code.array;

public class ViewQuestion {

}


/**
 *  ()中为为记熟 重点背诵的
 *
 * 1.设计模式用到过吗    (工厂类实现了applicationContextAware接口， 重写setapplicationContext方法读取配置文件中内容)
 *    用到过，在天狮集团项目中有个生码功能，生码可以选择升1-3级码；并且对应的代码逻辑是不同的，针对这块 我采用的是  工厂模式+策略模式
 *    具体实现流程是
 *    1)在yml配置文件中 声明一个codeType属性。里面有三个值，对应前端传递的值
 *    2)还有一个工厂类 实现了applicationContextAware接口  重写了setapplicatonContext方法，使用map集合读取配置文件中的codeType
 *    3)还有一个对外提供服务的方法，这个方法根据传入的值 会返回一个具体的策略对象，由策略对象去执行具体的业务逻辑代码
 *    这样写的好处是 符合开闭原则，并且在新增需求的时候 只需要新增类或者方法即可，不需要额外的改动业务逻辑代码
 *
 *    衍生问题： 其他读取配置文件的方法  @Value("${pods.username}")  @Value+$
 *
 * 2.map集合用过吗介绍下：
 *      map是一个接口，是key-value形式，他有hashMap等实现类，
 *                   (hashMap是一个线程不安全的集合  ===>可以通过Collections.synchronizedMap() 或者 ConcurrentHashMap将它变为线程安全的)
 *                                                              （线程不安全体现在扩容时）
 *                  hashMap在jdk1.7及之前底层是由数组+链表组成       (采用头插法可能会造成循环链表)
 *                           jdk1.8及之后底层由数据+链表+红黑树构成    (可能会造成数据覆盖)
 *                                                                链表转红黑树      (同时满足：数组长度>=64，链表长度>=8)
 *                                                                 红黑树转链表    (满足任一条件：扩容时拆分树节点后，子树节点数 ≤ 6 删除树节点后，树节点数 ≤ 6)
 *
 *                  hashMap在新建的时候并不会立马分配内存空间，而是在put时会分配一个16字节的内存空间，每次扩容为原来的2倍，扩容因子默认为0.75
 *                  当hashmap中的元素>当前容量*扩容因子会进行扩容
 *
 *      (java集合分为connection和map    connection存储单列 list和set为connection子接口， list是有序可重复， set无须不可重复)
 *
 *
 * 3。（线程池相关问题）
 *    线程池有七个核心参数
 *      最大线程数=(核心线程数+临时线程数)、
 *      核心线程数、
 *      等待队列、   ArrayBlockingQueue 基于数组实现 有界，底层采用一把锁   LinkedBlockingQueue 无界
 *      线程工厂、
 *      拒绝策略、默认抛出异常 还有一种使用当前线程完成任务(临时线程)
 *      最大空闲时间、
 *      时间单位、
 *         线程提交的两种方式  execute()  无返回值                        使用场景    异步记录日志（无需等待结果)
 *                   submit()   有返回值 返回一个Future对象   future.get()获取执行结果    使用场景  多线程调用第三方接口获取返回值set到对象中 然后返回前端 必须等待全部完成
 *
 *     (线程池执行流程)
 *     如果是有界队列   线程先放  核心线程，核心线程若满，放入队列中，若队列已满，创建线程至最大线程数 ，若已达到最大线程数触发拒绝策略
 *     若是无界队列(线程池默认是无界队列)    线程先放  核心线程，核心线程若满，放入队列中，若队列已满，不会创建至最大线程数也不会触发拒绝策略，会一直创建直到oom
 *
 *
 *
 *
 * 4.索引失效场景，是我在工作中碰到并且总结下来的
 *      1。like以百分号开头
 *      2。不满足最左匹配原则   索引顺序如果为 a b c，
 *                                          查询条件如果为 a b 生效
 *                                                       b c 那么会失效，
 *                                                       a c 仅a部分生效
 *      3。or两边必须都有索引
 *      4。如果索引字段类型是varchar的话，在写sql时必须要加 单引号 否则会失效
 *      (5.使用联合索引时，如果前一个索引是范围索引那么后面的索引会失效)
 *      (6.索引条件不能有聚合函数)
 *
 * 5.做过哪些索引优化？
 *      1)业务场景是查询当前经销商和下级经销商的订单以及产品信息
 *          问题出现：客户反馈前端界面查询超时，出不来数据
 *          排查： 根据 界面定位到接口，然后再去定位sql。把sql扔到navicat中执行了一遍发现用时120s左右
 *          经过排查问题出现在 一个连接表的操作导致sql变慢，一共是连接四五张表  经销商表里面存放的是所有的经销商信息，使用parent_id去标识子集经销商
 *          因为业务查询的是 当前经销商和子集经销商的数据 所以sql条件写的是 factory_dealer.id=? and parent_id=?
 *          问题出现在parent_id上面， 我是采用主键+覆盖索引进行优化，在执行sql之前，将子集经销商id查询出封装为一个ids列，并将当前经销商id放入
 *          修改sql条件为 where factory_dealer.id in {ids} 将索引优化到1s左右
 *
 *
 *6.(线程安全问题) ***
 *      transactional+sync 关键字导致产生脏读数据
 *          业务场景为；客户扫码发货，有一定并发，会出现多个人扫描一个订单的情况
 *          客户反馈：明明一共扫了50箱货，最后只登记了45箱。
 *          排查日志发现有脏读的现象，查询当前订单中产品的数量时；多次读到了相同的数据
 *
 *          当时很疑惑，明明用 sync锁了为什么还会出现脏读现象，并且mysql的事务隔离级别是默认的可重复读 是能够预防脏读的产生
 *          后面通过翻阅博客等手段 了解到 sync锁的范围并没有锁住整个事务，具体的执行流程是
 *              transactional是通过aop代理来实现的
 *              1)开启事务
 *              2)加锁
 *              3)业务逻辑执行
 *              4)释放锁
 *              5)事务提交/回滚   但是此时已经释放锁了，但是累加的数据还未更新到表中
 *
 *              导致另一个事务读取到的订单产品数据是累加之前的
 *
 *              不是数据库的事务隔离级别出现了问题，而是sync锁的范围并没有锁住整个事务
 *
 *          解决方案就是扩大sync锁的范围  能够锁住整个事务 解决问题
 *
 *
 *7. (springBoot自动装配原理/介绍下spring和springBoot的区别)
 *     SpringBootApplication是springboot的核心注解，它由三个注解构成
 *     1)EnableAutoConfiguration：是实现自动化装配最核心的注解，它由@import注解来实现读取当前项目的spring.factories文件中的内容，
 *                                并根据预先定义好的Bean条件决定是否自动装配到spring容器中
 *     2)SpringBootConfiguration：springboot配置类
 *     3)ComponentScan：组件扫描 将标记的类(@service) 注册为容器中的bean
 *
 *
 * 8.(springMVC的执行流程)
 *
 *
 *
 *
 *
 *
 *
 */
